home *** CD-ROM | disk | FTP | other *** search
/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-21 / qwhite.zip / IA.TEC < prev    next >
Text File  |  1992-03-13  |  11KB  |  202 lines
  1. ID:IA QEMM-386 and Keyboard Behaviour
  2. Quarterdeck Technical Note #221
  3. by: Michael Bolton
  4. Release date: December 17, 1991
  5. Last revised: January 22, 1992
  6.  
  7.                        QEMM-386 AND KEYBOARD BEHAVIOUR
  8.  
  9. INTRODUCTION
  10. ============
  11.  
  12. Users sometimes experience "sticky shift keys" under QEMM -- the symptom is 
  13. that the Shift, Control, or NumLock keys appear to take effect even though 
  14. they have not been pressed.  The IA parameter to QEMM can sometimes fix this 
  15. problem.  To use it, simply add IA to the end of the QEMM line in CONFIG.SYS 
  16. as follows:
  17.  
  18. DEVICE=C:\QEMM\QEMM386.SYS <your other parameters> IA
  19.  
  20. If this does not work, QEMM can provide no other solution to the problem.  
  21. When IA is used, QEMM does not affect keyboard activity.
  22.  
  23. THE REAL CAUSE
  24. ===============
  25.  
  26. The probable source of the difficulty is a program that intercepts or 
  27. redirects Interrupt 9, which is responsible for detecting keyboard activity.  
  28. TSRs often do this, especially those which pop up under the control of a hot 
  29. key, or those which monitor or accelerate keyboard performance.  Application 
  30. programs can occasionally exhibit this behaviour as well.  Such a program 
  31. reads the keyboard, and then decides whether the key is important to its 
  32. operation: if it is, the program interprets the key and performs one of its 
  33. own functions; if not, the program passes the keyboard event to the previous 
  34. owner of INT 9.  Note that several programs may be attempting to monitor the 
  35. keyboard this way, and that several programs may be inspecting the keystroke 
  36. before it eventually reaches the system ROM BIOS, which is the original 
  37. handler of INT 9.
  38.  
  39. Before the appearance of the PC-AT architecture, the procedure to read the 
  40. keyboard was:
  41.  
  42.   1) inspect the keyboard port
  43.   2) reset the keyboard
  44.  
  45. After the reset, another key can be put into the keyboard port.
  46.  
  47. On the PC-AT and later machines (i.e. since 1985), the correct method is:
  48.  
  49.   1) disable the keyboard;
  50.   2) read the keyboard port (this would allow a new key to be put into the 
  51.      keyboard port if the keyboard had not been disabled by the first step);
  52.   3) reset the keyboard (which actually does not have any particular function 
  53.      in this newer way of doing things);
  54.   4) re-enable the keyboard (which allows a new key to be put into the port).
  55.  
  56. To further complicate matters, machines that have a PS/2-style mouse must 
  57. disable that as well, but it is dangerous to do so if the mouse port does not 
  58. exist!
  59.  
  60. In fact, programs should be using another method (INT 15, Function 4F) to read 
  61. the keyboard -- which avoids all of these problems entirely.
  62.  
  63. Many programs apparently do not implement the later, correct methods of 
  64. reading the keyboard.  Consequently, the old-style read-and-reset method 
  65. allows a new key to come in, perhaps before the program has had a chance to 
  66. pass the first key to the previous interrupt handler.  By the time a decision 
  67. has been made to pass the key along, a different key may be in the keyboard 
  68. port.
  69.  
  70. Keyboards do pace the keys they put in the keyboard port, and so if not too 
  71. much time elapses between reads of the port, the correct key will be passed.
  72.  
  73. Several things can affect this:
  74.  
  75.   1) If some I/O ports that are accessed during this period are trapped by 
  76.      QEMM, then that slows down the sequence of code, increasing the 
  77.      likelihood that a new key may be in the keyboard port when it is read by 
  78.      the next program down the chain.
  79.  
  80.      Programs which read the keyboard read I/O port 64 as part of the process.  
  81.      Port 64 controls the state of the the A20 address line, which must be 
  82.      enabled for access to extended memory.  When the A20 bit is enabled, 
  83.      programs may also read and write to extended memory addresses instead of 
  84.      wrapping to the bottom of conventional memory addresses.  By default, 
  85.      QEMM traps port 64 to detect programs which are attempting to manipulate 
  86.      the state of the A20 line, which unfortunately shares its I/O port with 
  87.      the keyboard controller. (The logic underlying the decision to place such 
  88.      a crucial piece of system control hardware on the keyboard controller is 
  89.      lost in the mists of time.  All that is known is that there was a spare 
  90.      bit in one of the registers on the keyboard controller, and a need for a 
  91.      place to put the bit that would enable and disable the A20 line.) The 
  92.      IGNOREA20 (IA) parameter instructs QEMM to refrain from trapping this I/O 
  93.      port, and thus causes QEMM to ignore the keyboard completely.  Note that 
  94.      on Micro Channel machines, QEMM does not monitor port 64; it monitors 
  95.      port 92 instead (since the latter, rather than the former, is used to 
  96.      control the state of the A20 line on Micro Channel machines), and 
  97.      therefore IA will have no effect on Micro Channel IBM PS/2s or other MCA 
  98.      machines.
  99.  
  100.   2) QEMM puts the processor into Virtual 86 mode when QEMM is in an ON state -
  101.      - essentially when expanded memory or High RAM is being provided. The 
  102.      same is true of any 386 expanded memory manager --whether QEMM, DOS 5's 
  103.      EMM386, Compaq's CEMMP, or the like; Virtual 8086 mode is necessary to 
  104.      provide expanded memory or High RAM. In V86 mode, many instructions take 
  105.      longer than in real mode, and interrupts themselves are slowed down, 
  106.      again increasing the possibility that a keyboard event might be missed. 
  107.      In this case, your 386 memory manager contributes to the overhead of 
  108.      processing interrupts, but it is not actually causing the problem.
  109.  
  110.   3) The above two scenarios are not usually a problem with most keys, simply 
  111.      because people do not type fast enough to have another key available when 
  112.      the next TSR (or the BIOS) tries to read a key. But on the newer 101-key 
  113.      keyboards -- which first appeared in 1987, and which have separate number 
  114.      and cursor keypads -- the cursor pad keys are special when NumLock is on.  
  115.      A single Arrow key on the cursor pad with Numlock on generates six 
  116.      keyboard interrupts on the downstroke and six more on the upstroke.  They 
  117.      are:
  118.  
  119.           1: "A New-Keyboard-style key will be the next key"
  120.           2: Left shift down
  121.           3: "A New Keyboard key coming next"
  122.           4: Arrow down
  123.           5: "A New Keyboard key coming next"
  124.           6: Left shift up
  125.  
  126.      These come in rapid succession, controlled by the keyboard pace rate. If 
  127.      there is a misbehaved keyboard interrupt handler in the chain, one of 
  128.      these keyboard interrupts might get lost by the time it reaches the BIOS 
  129.      handler. If the interrupt that is lost is the fake upshift, the BIOS will 
  130.      think the shift key is still down.
  131.  
  132. The IA parameter to QEMM reduces the overhead on reads of port 64, and thus 
  133. might improve the situation such that the problem disappears --which will 
  134. alleviate situation (1) above.  Removing QEMM will alleviate situation (2) 
  135. above, but this is not likely to be a particularly viable solution, since you 
  136. lose all of the benefits of 386 memory management --and therefore most of the 
  137. benefits of the 386 architecture.  Note that other 386 memory managers will 
  138. probably cause your system to exhibit similar behaviour.
  139.  
  140. DESQview does hook the keyboard interrupt, but it uses the proper technique to 
  141. do so.  QEMM does not hook the keyboard interrupt, and has only an incidental 
  142. effect on the keyboard as discussed above -- QEMM adds a small amount of 
  143. overhead to the system generally, and therefore can appear to be the "cause" 
  144. of the problem.  However, neither QEMM nor DESQview, in and of themselves, 
  145. will cause sticky shift keys; the direct cause of invisibly held-down shift 
  146. keys is determined by some other aspect of your system.
  147.  
  148. IDENTIFYING THE CAUSE
  149. =====================
  150.  
  151. Manifest can help you determine which program or programs are hooking INT 9.  
  152. Go into Manifest by typing MFT at the DOS prompt.  Press F for First Meg, I 
  153. for Interrupts, and F3 for list by number.  In the middle of the list, you 
  154. should see:
  155.  
  156.      INT 09: Keyboard Event      0C43:7114 STINKKEY
  157.  
  158. What you see as the values displayed above will differ.  The above address and 
  159. program are totally fictitious, and where the interrupt is pointing may be 
  160. affected by the STACKS settings in CONFIG.SYS.  You should ensure that the 
  161. line STACKS=0,0 appears in CONFIG.SYS, so that device drivers which have 
  162. hooked INT 09 will display on this list.  This will be necessaary if Manifest 
  163. is reporting that the owner of INT 09 is "DOS Stacks".
  164.  
  165. In the example above, INT 09 is being handled by a TSR called STINKKEY; it is 
  166. probably our culprit.  Try removing the TSR (or device driver) that is hooking 
  167. INT 09, and see if that cures the problem.  If not, continue removing TSRs or 
  168. device drivers that are hooking INT 09 until the offender is found. If the 
  169. problem happens from within an application, load Manifest as a TSR, and pop it 
  170. up from within the application that exhibits the problem.  Note that the 
  171. application with the problem must be running in text mode (not graphics mode) 
  172. for Manifest to pop up.
  173.  
  174.  
  175. FIXING THE PROBLEM
  176. ==================
  177.      
  178. Temporary relief from sticky shift keys can sometimes be provided by tapping 
  179. the key that appears to be stuck.  The BIOS will then see the proper state of 
  180. the shift key, and things should work normally. Keyboards have on-board 
  181. controllers which determine some of the behavior of the keyboard.  
  182. Specifically, the keyboard controller governs what scan code is generated by 
  183. each key, and how much time should elapse between keyboard interrupts when a 
  184. keystroke generates multiple interrupts.  Therefore, different keyboards might 
  185. pace differently, and so exchanging the keyboard for another might affect the 
  186. problem -- and possibly improve things.  One chipset that we are aware of has 
  187. in its setup an option for a "Fast A20 Gate Enable"; toggling this setting has 
  188. helped some users, and similar options on other chipsets could help. Some 
  189. companies claim that BIOS upgrades can help alleviate sticky shift keys.  All 
  190. of these are side issues, however.  The actual problem is that a program in 
  191. keyboard interrupt chain -- probably the last one loaded -- is not reading the 
  192. keyboard properly.  The simplest solution may be to remove the offending 
  193. program.  If you require that program for a definite purpose, and if no other 
  194. well-behaved substitute can be found, consult the program's authors or 
  195. publishers for assistance.
  196.  
  197.   ************************************************************************
  198.   *This technical note may be copied and distributed freely as long as it*
  199.   *is distributed in its entirety and it is not distributed for profit.  *
  200.   *         Copyright (C) 1991-2 by Quarterdeck Office Systems           *
  201.   ************************ E N D   O F   F I L E *************************
  202.